feat(SERVE-RECIPE-ARGS): accept two inert recipe flags so a published vllm serve line reaches model load (#606) - #624

…load (#606)

FOLLOWING_AGENTS_PROTOCOL

vllm-serve rejects any argument it does not recognise (server_main.cpp:440). That
is the right default, and it is why two flags that mean nothing to us stop the
server before it loads a model: --enable-auto-tool-choice, which 89 of the 157
official vLLM recipes pass, and --trust-remote-code, which 82 pass. We parse tool
calls whenever --tool-call-parser resolves, so there is no second gate to open;
and we have no Python, so there is no remote code to trust. Both are inert, and
both abort -- including for Qwen3.5-27B, which we ship token-exact and gated. The
kernels are not what stands between a user and a running server here.

The spec is deliberately narrow about what the seam may swallow. An enumerated
table, one entry per flag with the reason it is inert; anything unlisted still
aborts, because silently accepting --tensor-parallel-size would let a user believe
they got tensor parallelism, and that is the failure mode this exists to prevent.
Flags inert because we LACK the capability -- TP, EP, --mm-encoder-tp-mode -- are
explicitly excluded and keep aborting. So is --language-model-only (#607), which
is a real capability gap wearing the same costume.

Two things the spec records rather than papers over. cli_args.py:395 makes
--enable-auto-tool-choice without --tool-call-parser a TypeError upstream, so
inert must not mean unvalidated and the mirrored failure is a named test case. And
upstream defaults --tool-call-parser to None where we default it to hermes, so
upstream's flag genuinely gates something ours cannot -- pre-existing, out of
scope, and called out so the notice text does not overclaim parity.

ENGINE_ROWS 152 -> 153 for the new row, with the justification the checker's own
comment ledger asks for. No checker semantics change: the row claims no seam, no
test and no USAGE entry, because none exists yet.

Spec and records only, no product code touched.
scripts/agent-preflight.sh --staged: exit 0.

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]

…nd record the literal-scanning trap (#606)

Two things the next person on this row would otherwise re-derive, so the spec's
Now section states them.

The PR cannot go fully green, and not because of this change. windows-msvc-cpu
and windows-msvc-vulkan fail with test_openai_api_server.exe exiting
-1073740791, which is 0xC0000409, STATUS_STACK_BUFFER_OVERRUN, already tracked
as #584. Attributed rather than assumed: #625 fails with the byte-identical exit
status while touching no src/ or include/ path at all, so a records-only PR
reproduces it. test_openai_api_server is not a consumer of this seam either --
it never calls ParseArgs.

And the trap this change walked into. check-windows-portability.py scans the
shipped server sources with comments stripped but STRING LITERALS INTACT, and
its POSIX-call pattern matches a bare `open` before a parenthesis, so prose in a
user-facing message was reported as an unguarded POSIX call reaching Windows.
The gate is Windows-only and is not part of scripts/agent-preflight.sh, which
means an all-green local preflight says nothing about it. That is the part worth
writing down: the failure mode is not the rule being wrong, it is a gate the
local preflight does not cover.

Record only. No product code, no test, no checker touched.
scripts/agent-preflight.sh --staged: exit 0, all gates green.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]

…ment and three anchors that disagree with the tree (#606, #631)

Repairs the fresh scoped review of #624. The review's verdict was FAIL on the
RECORD and explicitly not on the code: the seam, the mirrored cli_args.py:395
validation, the notice and the four tests all reproduced exactly, mutation
included. Nothing in `src/` or `tests/` changes here, by design.

1. AN UNNAMED RED LANE (the one that matters). The spec's `## Now` attributed
   the red CI to the two `windows-msvc-*` lanes and #584, so a reader was told
   the CPU lane was green. It is not: `build-test-cpu` fails on
   `test_cpu_threadpool`, 1 of 404, at `ratio 101.567` against a fixed `< 100.0`.
   AGENTS.md § Gates wants exactly one result per applicable rule, and a lane
   omitted reads as a lane satisfied. It is now named, with the same attribution
   rigor already spent on #584 rather than a bare "unrelated": the guard divides
   two wall-clock medians, the 2-core runner collapsed the DENOMINATOR to
   0.48 us, and argument parsing inside `ParseArgs` has no path to a threadpool
   dispatch ratio. Already filed as #631 while the review was running, so this
   references that issue rather than opening a second one.

   The evidence is three observations of the same code, and the third is the
   informative one. The 2-core runner read 101.567; #631's table read 2.699 on a
   20-core box; rebuilding the reviewed head here read 0.990872 on a 20-core box
   (9 cases / 9 passed, 19602 assertions, `Status: SUCCESS!`). Two same-class
   boxes 2.7x apart is the finding: the statistic will not carry a fixed
   threshold. Recorded rather than smoothed, and the middle row is kept
   attributed to #631 rather than restated as mine. Also recorded because it
   falsifies the test's own claim at `test_cpu_threadpool.cpp:496` that it can
   "be trusted ... never to fail spuriously on a busy one".

   NOT fixed in flow, deliberately. Repairing that guard changes a gate's
   semantics, which AGENTS.md routes through its own spec and red-before
   evidence; and raising 100 to a larger number would be widening a scope to
   turn a red gate green, which is the specific thing forbidden.

2. A COMMENT FALSE ABOUT ITS OWN TREE. The `ENGINE_ROWS` 152 -> 153 justification
   in `check-agent-record.py` said the row is `SPIKE` and that "no seam, no test,
   and no `docs/USAGE.md` entry exists yet". All four were true at the spec
   commit `0d8274ac3` and none is true at this head. `main` is squash-only, so
   the single landing commit would have shipped a comment contradicted by files
   in the same commit — AGENTS.md § History is git: the record cannot disagree
   with the tree.

   Corrected to state the tree rather than framed "as of the spec commit". The
   as-of framing would also have been accurate, and is rejected on purpose: it
   dates a justification to a commit that squash-merging deletes, so the reader
   who meets the line has no way to check it. A comment that describes the file
   it sits in is verifiable by looking; one that describes a vanished
   intermediate is not.

3. THREE STALE LINE ANCHORS, in `.agents/engine-matrix.md` and the spec.
   `b7eaadd07` inserted a 4-line comment at `server_main.cpp:299-302` and shifted
   everything below it. Re-derived from the file rather than from the review's
   table, and the table was right: `FindAcceptedInertArg` 308 -> 312, the parse
   branch 501 -> 505, the mirrored validation 557 -> 560. `kAcceptedInertArgs:289`
   sits above the insertion and all four test anchors (`:141`, `:165`, `:188`,
   `:212`) are exact; those five are untouched.

4. A FORWARD REFERENCE, made legible instead of resolved. The spec cited
   `roadmap_v1.md` § Recipe-surface sweep, which does not exist there yet — it
   arrives with #612, along with the intake rows for #605-#608. The citation now
   says so. #606 is deliberately NOT added to the intake table: #612 owns those
   keys, and two branches adding the same keyed record merge cleanly and then
   define it twice, which has already happened twice in this campaign.

5. `InertArg::takes_value` recorded as a named cold path. Both shipped entries
   are `kNoValue`, so the value-consuming branch is unexercised and cannot be
   tested without inventing an entry. The obligation moves to the spec: the first
   entry with `takes_value == true` owes a test in the same change. No
   speculative code and no speculative test.

check-pr-size requires paired mutation evidence for any change to
`scripts/check-agent-record.py`. This PR already carries it —
`test_agent_record.py`'s `test_serve_recipe_args_row_is_inside_the_engine_ratchet`
is the semantic evidence for the 152 -> 153 bump, and the checker verifies the
pair over the whole PR range. The edit above is comment-only and changes no
behavior that any test could newly pin, so no test is added: a test written to
satisfy a counter rather than to defend a guarantee is the thing that rule
exists to prevent.

Verification, all foreground and observed: `scripts/agent-preflight.sh --staged`
exit 0, "All gates green"; `scripts/check-windows-portability.py` exit 0,
"Windows portability contract OK" (it is Windows-only and not part of preflight,
which is how the earlier `open (` trap got through); each corrected anchor read
back from the file it points into.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]